In distributed computer networks, communication between the various distributed participant systems of the network is often through asynchronous exchange of messages. In asynchronous messaging, software program applications send and consume messages. The message exchange is asynchronous in that an application sending a message does not need to wait for a remote application to receive that message. Thus, there is no need for all elements of the infrastructure linking the computers on which the applications are run to be available at all times.
Generally, communication between participant systems of a distributed computer network can be according to a pessimistic communication protocol or an optimistic communication protocol. As an example, a computer system of a purchaser of goods may run a software program application that allows the purchaser to electronically place a purchase order. The purchase order application generates and stores locally a first data object representing the order, and effects sending of a message containing the data object, i.e., the order, via the computer network to an order processing software program application run on another computer system at the site of a supplier of the requested goods. The order processing application handles and processes incoming orders. Once the order processing application receives a new purchase order, it creates and stores locally a second data object that corresponds to the first data object.
In practice it frequently happens that a purchaser, after having successfully placed an order with a supplier, wishes to change (modify) his order, for example, because the quantity or size of the required goods has changed. Thereafter, the purchaser may wish to modify his order a second time, and perhaps yet even more times.
If a pessimistic communication protocol is used for communication between the purchaser and supplier systems, a modification of the order by the purchaser is allowed only until after a confirmation message sent from the supplier system has been received by the purchaser system in response to an earlier modification. In other words, the purchaser, who has just entered a modification into his system, has to wait until a message (answer) confirming receipt of the modification is received from the supplier system, before he is allowed to enter another modification. The supplier's confirmation can be positive (he accepts the modification) or negative (he rebuffs the modification). On the other hand, if an optimistic communication protocol is used, the purchaser can enter a modification of his order even before having received a confirmation of an earlier modification from the supplier system.
Pessimistic communication protocols are usually employed where conflicts between the participant systems may easily occur, e.g., where a supplier is not sufficiently flexible to respond to late modifications of an order short before start of a production run or to handle plural modifications within a short period of time. For example, if an order is sent from a purchaser to an outside supplier, modifications of the order are likely to be acceptable for the supplier only well before execution of the order. This is particularly true if the purchaser and supplier resort to software products from different providers for handling their electronic business matters. A standard pessimistic communication protocol often used in today's world of electronic commerce is, e.g., RosettaNet.
An optimistic communication protocol is convenient in a situation where the supplier is highly flexible and able to react on modifications of an order even short before commencing execution of the order. This is often true where purchaser and supplier, or more generally collaborating business partners, rely on software products from the same software provider using similar or the same standards, procedures, interfaces, data structures, instruction sets, etc. It is also determinative for the choice of the type of communication protocol used whether or not the systems are able to store and visualize process conflicts as part of their data design and business process.
When designing and programming a scheme for the communication between participant systems of an asynchronous messaging computer network, a software developer, or a team of developers, hitherto face a dilemma of choosing whether to implement an optimistic protocol or a pessimistic protocol. Voting for an optimistic communication protocol implies forgoing the openness of a pessimistic communication environment, i.e., the possibility of having most diverse software systems of different manufacturers collaborate through a computer network. Electing a pessimistic communication protocol means waiving flexibility and ease of use of an optimistic communication environment. Thus, it is highly desirable to have a communication protocol that preserves both openness of a pessimistic system and customer friendliness of an optimistic system.